RADIUS servers can themselves act as RADIUS clients
and forward authentication and/or authorization request to another
RADIUS server. For example, an ISP may use a RADIUS server to protect
access to its network. If its customers are using the ISP to obtain
access to their organization's remote access services, the organization
may want to use its own database for authentication. Alternatively, an
organization may want remote RADIUS servers at its own remote offices to
forward requests to a central location. When IAS is used to forward
requests to another RADIUS server, IAS is acting as a RADIUS proxy.
Setting up IAS to act as a RADIUS proxy entails a few general steps. First, you must configure a remote RADIUS server group
(that is, a list of one or more RADIUS servers to which connection
requests are forwarded by the proxy). If one of the servers is
unreachable, the proxy will attempt a connection with another member of
the group. You must also create a connection request policy
that forwards authentication requests to the remote RADIUS server
group. Finally, you must either delete the default connection request
policy or change the processing order so that the new policy is
evaluated first.
1. Configuring a RADIUS Server Group
The servers in the
RADIUS server group may be administered by another person, or even by
another organization. It is critical that administrators of the RADIUS
servers in the RADIUS server group and the RADIUS proxy administrator
have the correct information on the other's servers. Before configuring a
RADIUS server group, collect the information required and test
connectivity to these servers. Then, from the console of the RADIUS
proxy, configure the RADIUS server group.
To configure a RADIUS
server group with two servers, begin by clicking Start → Administrative
Tools → Internet Authentication Service. Select and expand the
Connection Request Policies node. Right-click Remote RADIUS Server
Groups and the select New Remote RADIUS Server Group. Then click Next.
Select "Typical (one primary server and one backup server)." Enter a
group name, as shown in Figure 1, and then click Next.
In the next screen shown in Figure 2,
enter the server name or IP address of the primary server in the
"Primary server" field and the backup server in the "Backup server"
field. Click the Verify button next to the field for each server to
verify the servers can be reached from the RADIUS proxy server. Enter
the shared secret that will be used by the RRAS servers to connect to
the proxy in the "Shared secret" field and retype the shared secret in the "Confirm shared secret" field. Click Next followed by Finish.
To edit the default
properties for each server, double-click on the server group in the IAS
console, then double-click on the server. Select the
Authentication/Accounting tab. Use this page to modify ports used for
authentication and accounting and modify shared secrets, as shown in Figure 3.
If the same shared secret is used for authentication and accounting,
check the box "Use the same shared secret for authentication and
accounting." The same shared secret might not be used if you have
configured authentication and accounting to be managed by different IAS
servers. If such is the case, and each IAS server uses its own shared
secret, then make sure this box is unchecked and enter the correct
shared secret for each server.
Select the Load Balancing tab, as shown in Figure 4, and modify information on the server priority. An entry of 1
indicates that this server is the primary server. (A connection to the
primary server will be attempted first.) Enter larger numbers to
indicate the order in which connection requests should be attempted.
Connections to servers will be attempted in sequence, starting with the
lowest number. In Figure 4, this server is given a priority of 2,
which means that it will be used if the primary server cannot be
contacted. If multiple servers are assigned the same priority, then use
the Weight box to indicate how often connection requests should be sent
to this particular server. In the Figure 4, the number 50
in entered to indicate that 50% of the requests should be sent to this
server. Adjust timing information in the fields under "Advanced
settings" as necessary to accommodate any network latency.
Click OK to close and implement the changes.
2. Configuring a Connection Request Policy
An IAS RADIUS server is, by default, configured to act as a RADIUS server and uses the default connection request policy
: use Windows authentication for all users. Connection request policies
specify how incoming connection requests are handled by IAS. To
configure IAS as a RADIUS proxy server, configure a new connection
request policy.
To create a new
connection request policy, begin by opening the IAS console. Right-click
Connection Request Policies and select New Connection Request Policy.
Enter a name for the request policy, as shown in Figure 5, and then click Next.
Click to select "Forward connection requests to a remote RADIUS server for authentication," as shown in Figure 6, and then click Next.
Enter the "Realm name"
(which is the server name of the RADIUS server). Select the "Server
group" from the drop-down list, as shown in Figure 7.
Then click Next followed by Finish. A new server group can be created
at this time by clicking the New Group button and following the wizard.
The connection request policy can be edited. Double-click the policy and
edit much as you would a Remote Access policy.
If
the username does not include the domain name, the default domain name
is used. This name is the name of the domain of which the IAS server is a
member. You can specify the default domain by editing the DefaultDomain
value at HKEY_LOCAL_MACHINE\Sys-
tem\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\. |
|
Whether the IAS server is used as a RADIUS server or as a RADIUS proxy, security
is extremely important. The IAS server should be secured and
communications between RRAS and IAS should also be hardened, For
example, if these communications can be intercepted and read, sensitive
information such as passwords might be attacked and later used to
compromise networks. If a rogue RRAS server can successfully connect to
the IAS server, it might also be possible to fraudulently obtain remote
access to your network.